[Previous] [Next] [Index]
[Thread]
Re: _DNS_ security problems
> On Feb 25, Dan Stromberg <strombrg@test34a.acs.uci.edu> wrote:
> > Subject: _DNS_ security problems
>
> Yes, this is a topic for the bind list. I disagree that the solution lies in
> modifying DNS, which works very well for its intended purpose, and not very
> well as a secure identification mechanism (sometning is was _not_ designed to
> do). The protection, in my opinion, needs to be at a higher level. IMHO.
>
> In any case, couldn't Java do a getpeername() on the socket used to grab the
> 'master' class? Then it could use the peer IP address as the source host,
> refusing to load from or connect to any other IP address.
This fails in the face of web proxies; the address you connect to (and
thus the result of getpeername()) is usually your proxy, not the
applet's home.
Granted that I'm paid to be paranoid, but I have yet to see compelling
need for allowing _any_ network connections by applets. All the
justifications I've seen so far involve hand-waving promises of future
nifty interfaces, while on the flip side the risks are _very_
immediate, and _very_ real.
I don't consider browser-level options for controlling applet security
strong enough, either. Imagine, if you will, a web page that says
I'd like to show you something really cool, but in order for it to
work you need to go to your Preferences list and turn on network
access for me.
What are the chances that somebody inside your security perimeter gets
tricked? User education can help, but the probability is still far
from zero.
- irving -
Follow-Ups:
References: